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METHODS AND APPARATUS FOR CONDUCTING 
SECURE, ONLINE MONETARY TRANSACTIONS 



Reference to Prior Applications 



This application claims priority of U.S. provisional application Serial No. 
60/131,369 filed April 28, 1999, the entire contents of which are incorporated herein by 
reference. 

Field of the Invention 
The present invention relates generally to monetary transactions conducted over a 
communications network and, more particularly, to a system, method, and apparatus that 
provide a secure and portable payment method for online transactions. 



The Intemet provides a forum in which consumers and merchants can engage in 
electronic shopping from globally diverse locations with absolute availability. The 
Intemet continues to capture a growing share of retail business, as evidenced by the 
tremendous increase in online business-to-consumer transactions over the past several 
years. 

Along with this growth, however, comes a demand by consumers for secure 
online payment methods. Most online businesses only accept credit cards for payment, 
and so the sensitive financial and personal data contained on a credit card is broadcast 
over the Intemet; i.e., through multiple computer systems providing the means to read or 
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capture the data. For this reason, prospective online purchasers remain reluctant to 
provide credit card information via the Internet, thus risking interception of the data for 
exploitative and criminal purposes by hackers. 

Some have attempted to address these issues with various inventions intended to 
secure the financial and monetary data relevant to the transactions. In general, three 
categorical approaches to security exist: encryption of the data, utilization of a single, 
authenticated channel for the transaction, or utilization of proprietary hardware devices. 

The first category, encrypted data, traditionally involves encoding the data 
themselves prior to transmission across a public communications network, and decoding 
the data when the transmission completes. One such scheme, private key, depends on a 
single secret known only to the consumer and the merchant. Another scheme, public key, 
publishes one key and maintains another key as confidential. The requirement in each 
scheme for a unique key for each user results in literally millions of encryption keys, and, 
therefore, a great potential for lost, stolen, or counterfeit keys increases. 

The greater the degree of security that a particular encryption algorithm provides, 
however, the greater the degree of the processing effort and resource utilization is 
required to complete the transaction. Conversely, protocol requiring minimal security is 
quite susceptible to decoding by a hacker. In general, all encryption carries the potential 
for a hacker to break the code, and the more extensive the use of the protocol, the more 
the opportunity for the hacker to observe the patterns of the encryption and decode the 
algorithm. Thus, various encryption protocols maintain the security of the data only for 
until such a time as a hacker breaks the code. 
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Some encryption methods use a combination of networks to complete a 
transaction. First, the method transmits the encrypted data over a public network for 
portions of the transaction associated with a low security risk, then shifts the data to a 
private network to perform portions of the transaction with very high potentials of 
5 security failure. Of course, this method restricts purchases to those merchants associated 
with the provider of the private network. Similarly, Internet transactions involving the 
electronic withdrawal of funds from a bank account for online payment also require a 
third-party gatekeeper to route the consumer's payment information over a private 
network to the financial institution, send the encrypted payment information on a second 

10 private network to the merchant, and then divert data pertaining to the remainder of the 
transaction to the consumer via the Internet. Alternatively, a security method may 
combine use of a packetized network, such as the Internet, and a switched network, such 
as the telephone network for voice transmission. U.S. Patent No. 5,729,594 to Klingman 
discloses such a method. 

15 Although these combined security methods decrease the risk of infiltration, they 

restrict the online shopping opportunities for the consumer to those online banks and 
merchants available via the gatekeeper. In addition, the costs associated with utilizing 
both private and public networks in combination greatly increase the cost of the online 
transactional business. 

20 The second category of security involves the configuration of a personal computer 

system of a consumer and a computer system of a merchant with proprietary hardware 
devices that cooperate to encode and decode the data for transmittal over the Internet. 
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The smart card, a small plastic card encoded with various data, is a primary example of 
this technology. The Smart card provides a means by which the consumer can easily 
transport the card; however, current configurations require the use of a propriety smart 
card reader device attached to the personal computer of the consumer. U.S. Patent 
5,870,473 to Boesch, et al. discloses an example of this method. This method of security 
generally requires, at a minimum, a proprietary card reader by all consumers and all 
merchants using a particular card. These devices are costly, system dependent, and non- 
mobile, and the dependency on the propriety hardware restricts opportunities for 
transactions to those consumers and merchants with the appropriate, propriety hardware. 

The third category of security involves transfer protocol security. Generally, this 
method incorporates adherence to a protocol directed at one or more logical layers of 
transport in a networking conceptual model. Usually, the personal credit card data in an 
online transaction must be encapsulated with computer-readable instructions to transport 
the data from one location to another; e.g., from application software to application 
software; from a diskette to a hard drive; or from a personal computer to a merchant's 
web site. For example, Secure Socket Layer (SSL) protocol utilizes data encryption of 
the information related to the channel of transmission; i.e., the transmittal information 
used to encapsulate the personal financial data themselves. This method of security also 
provides data authentication via digital certificates that offer the consumer and the 
merchant assurances that they actually are who they claim to be online, and that the data 
sent between the two is secure. 



4 
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Alternatively, the security method may employ the security mechanism at any 
logical layer in a networking model. For example, the U.S. Patent No. 5,671,279 
discloses a security method utilizing a secure connection in the Transmission Control 
Protocol (TCP) layer of the Open Systems Interconnection (OSI) layered architecture 
5 networking model, as developed by the International Standards Organization (ISO) of the 
current International Telephony Union (ITU). The data encryption portions of this 
method, however, remain susceptible to breaches of security for all the reasons 
previously stated. Digitally signed certificates require the involvement of a third-party, 
the issuer or guarantor of the certificate, and, therefore, build in an additional cost for 
10 security. 

Summarizing, the current art provides a level of basic security for Internet 
financial transactions in the form of data encryption. This method, however, does not 
provide perfect protection against infiltration. Furthermore, the likelihood of infiltration 
increases over time with any particular encryption algorithm due to the accessibility of 

15 the encrypted data to the public. Attempts to buttress security by utilizing third-party 
services and resources results in excessive costs to the merchant, the consumers, or both. 
As an additional factor, the combination of security methods often substantially restricts 
the transactional opportunities of the consumer and the merchant. Some of the methods 
currently available require significant system resources, resulting in excessive costs to the 

20 transacting parties and performance degradation on the systems involved. 

From the foregoing, it can be seen that a secure, simple, and cost-effective method 

for conducting online monetary transactions is needed to keep pace with the ever 

5 
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expanding Internet and the associated transactional opportunities. An advantageous 
means to this end must provide a highly secure, robust, universal, and cost-effective 
solution to conduct high-speed transactions over the Internet from virtually any location. 

Summary of the Invention 
5 The present invention provides a system, method and apparatus for conducting 

secure monetary and financial transactions over the Internet and other public networks. 
The approach may be used for various purposes, including automated payments for 
purchasing goods or services online. 

In a preferred embodiment, the system comprises a physical medium containing a 
10 series of one-time-use data tokens, each token being representative of a monetary value 
or transaction. The medium is provided in the form of a computer-readable, wallet-sized 
card, with the tokens preferably being encoded optically, though they may be encoded 
magnetically, graphically or any combination of the above. An authentication server (the 
"IMC" server), is used to verify the validity of individual media, and an accompanying 
15 protocol permits consumers, merchants, and payment processors to cooperatively 
authenticate users and initiate and complete payment transactions. The system and 
method accommodate multiple payment models, including business-to-business and 
business-to-consumer arrangements. 

The primary function of the physical medium is to provide consumers with a 
20 secure and efficient way to conduct electronic commerce transactions. The miniature 
size of the medium permits the consumer to carry the medium in a wallet or purse, and 
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the medium is suitable for use on almost any existing personal computer. When payment 
is required for an online transaction, the consumer simply inserts the medium into any 
standard, media-readable drive, which then reads the data embedded on the card. The 
invention enables transaction activities over a communications network at minimal cost, 
5 and operates independent of computer system platform, adaptable to the dynamics of the 
Internet and other public or private computer networks. The method also permits online 
monetary transactions to be completed in minimal time. 



Brief Description of the Drawings 

FIGURE. 1 is a state diagram which depicts the order of network calls in a proxy 
10 model embodiment of the invention; 

FIGURE 2 is a state diagram which depicts the order of network calls in a pseudo 
credit card embodiment of the invention; 

FIGURE 3 is a card holder ERD view; 

FIGURE 4 is a history ERD view; 
15 FIGURE 5 is a session ERD view; 

FIGURE 6 is a preferred network architecture according to the invention; 

FIGURE 7 is a drawing which depicts a preferred physical medium; 

FIGURE 8 depicts an altemative, magnetically encoded medium; 

FIGURE 9 shows a different magnetically encoded medium according to the 
20 invention; 
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FIGURE 10 is a diagram which shows a method for issuing providing and 
activating a physical medium according to the invention; 

FIGURE 1 1 is a diagram which depicts the events surrounding a mss distribution 
method for providing a medium to consumers; and 
5 FIGURE 12 is a diagram which depicts an alternative distribution and activation 

process. 

Detailed Description of the Invention 
This invention facilitates secure monetary and financial transactions over the 
Internet and other public networks for various purposes, including automated payments 

10 associated with purchasing goods or services online. Different implementation methods 
may be utilized, including systems based on proxy and psuedo-credit-card models. In 
each case, communications protocols are provided between a consumer, merchant web 
site, payment processor and a provider of the service (through an "IMC^ server"), 
enabling online transactions to proceed in a secure manner. 

15 An important aspect of the invention is the successful integration of merchant 

Web sites. The system provides the merchant with a clear and easily implemented 
procedure based on a set of web-based software components enabling a physical 
medium to be used as a secure web based payment instrument. To provide the 
inventive payment option, a merchant team need only complete the following relatively 

20 simple tasks: 

8 
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1) Modify the checkout page of their e-shopping cart so that it contains a 
small amount of script which, when downloaded to the consumer's 
browser, permits the selection of the inventive payment option. 

2) Add a small amount of processing logic that will respond to each payment 
5 authorization. For many e-merchants this code is, for the most part, 

already v^itten for the processing of conventional credit card transactions. 

3) Register by completing the merchant activation form on the IMC server. 
Among other things, this establishes the types of payment processors that 
will be used for payment settlement. 

10 Once the merchant has performed the above tasks, the e-shopping consumer will be 

presented with the IMC option at the checkout point. After the consumer chooses this 
payment option, a payment authentication page is downloaded, and this begins the 
payment session as described below. Once the payment session is complete, the 
merchant will receive notification from the IMC server, and will be ready to present the 

15 final confirmation (receipt) page to the consumer. 

Software Components 

The merchant has the choice of two methods for the integration of the inventive 
Payment Option. The easiest and fastest method is through a Link kit, and for the highest 
degree of customization an SDK option is available. The SDK option provides the most 
20 power and flexibility because the solution developed interacts directly with the an 
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Authentication Service using the programming language of the developer's choice (i.e., 
Java, C/C++, or Perl). 

The follow^ing sections discuss each softv^are component used in the Payment 
Process. An important point to keep in mind is that whether the merchant is using Link 
5 or the SDK options, the same underlying components are used. The only difference is 
that for the Link option each component is configured and delivered through an 
automated interface on the IMC server, thus circumventing most of the programming 
issues that need tending while working directly with the SDK. 

Consumer Browser "Checkout" Components 

10 1 . Payment Option . 

The Payment Option consists of a small piece of HTML script that is added to 
the web store checkout page, and must be designed to provide the correct visual 
feedback and user input so that the consumer may select the inventive service over the 
conventional payment options. A standard logo for the service is strongly 

15 recommended, and may be required by the merchant. The SDK and Link options both 
contain this logo in a .Gif and .Jpg format. 

2. Pavment Session Script 

The Payment Session Script is a piece of HTML script that belongs on a page that 
will be presented once the consumer has selected the Payment Option. A primary 
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function of this script is to direct the browser how to locate and initialize the 
Authentication Control, as described below. 

3. Authentication Control 

The Authentication Control is a software component that is downloaded to the 
5 consumer's PC and controls the Payment authentication and authorization process on the 
client machine. It is this component that directly reads the hardware device containing 
the physical medium and its security data. It also handles the communication of this 
sensitive data to the Authentication Service. 

Depending on the targeted consumer browser, this control can take various forms. 
10 For example if the browser is Win32 ActiveX enabled, the Authentication Control is a 
signed ActiveX control. For other browsers, the control comes in the form of a Signed 
Java Applet or a Netscape Plug-In. 



Merchant Server Components 

1 . Authorization Processing. 

15 When an e-shopping consumer uses the physical medium to make a purchase at a 

merchant web-store, the IMC server generates what is called a payment authorization 
message. This message informs the merchant whether the transaction was successful. 
Authorization Processing refers to the work that must take place on the merchant's server 
in response to this Authorization Message. Typically, this will involve updating an order 

20 database to initiate a request for the delivery of the merchant's product or service; and in 

some cases, generating the consumer receipt page (or failure message in the case of a 
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failed authorization). The merchant web store development team will use an API 
specifically developed to create the processing for incoming messages. 

An Authorization Message can be delivered to the merchant in one of the 
following three basic ways: Email notification, Http post, or through a custom network 
5 protocol based on RPC. In most if not all web store implementations today, there already 
exists the processing necessary to handle incoming authorizations from a variety of 
sources. Essentially, the payment option according to the invention essentially provides 
yet another payment type that should be easily introduced into the mix. The composition 
of the Authorization Message can be modified through the Merchant Account Manager, 
10 which is a web based administration tool for use by the merchant web store development 
team. An Integration Guide is preferably provided to assist the merchant development 
team in creating the Authorization processing. 

2. Merchant API 

For the merchants who choose to use the SDK option, they will be writing code 
15 which makes use of a set of modules and library functions provided in the Merchant API. 
This API will permit the developer a central method from which to extract incoming 
messages from the IMC server and process them into the merchant database, as well as 
generate feedback for the e-shopping consumer. 

iMC Server Components 

20 1. Card Database 
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The database of the physical medium stores the data necessary to manage the vital 
functions of the inventive service. This includes tracking each card, consumer, merchant, 
and payment method as v^ell as the consumer's shopping activity that includes each 
authorization request, whether the request was approved, and complete transaction 
history, 

2. Authentication Service 

The Authentication Service provides the communication components necessary to 
fully authenticate a physical medium. It is the server side counterpart that the 
Authentication Control must talk to. It forms the necessary hand shaking, IMC database 
access as well as conmiunication with the Payment Processor for payment authorization 
and settlement. 

3. Merchant Account Manager 

The Merchant Account Manager provides web-based access to all aspects of a 
merchant's account. The functions provided include registration, setup and managing a 
merchant account. For example, it provides the merchant access to information that 
controls which payment processors and financial institutions the merchant's payment 
transactions will be used for electronic settlement. 

4. Consumer Account Manager 

The Merchant Account Manager provides web-based access to all aspects of a 
customer's account. The functions provided include registration, setup and managing a 
customer account. 

13 
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Transaction Processing 

At least two basic models are available for integration into existing payment 
processing systems. Merchants can chose the implementation that best integrates with 
their checkout experience. According to the first method, the provider of the inventive 
5 service inserts itself between the merchant and the payment processor, and acts as a 
proxy between the consumer and the payment processor and merchant. The software 
interacts with the consumer to authorize the transaction and, in the final stage where the 
software provides an authentication token, the IMC server not only verifies the token but 
continues to process the transaction by obtaining an authorization from a payment 

10 processor and forwarding the authorization code to the merchant. 

In the second method, the provider of the inventive service operates in the 
periphery. The software in this case interacts with the consumer to authenticate a single 
transaction between the consimier and the merchant. It then generates a pseudo-credit 
card number that is submitted to the merchant to authorize the transaction. The 

15 merchant's software will forward the pseudo-credit card number to a payment processor 
as usual. The pseudo-credit credit card number is routed by the payment processor to the 
service provider to retrieve the consumers actual credit card number, expiration date, and 
billing address. 

The Proxy Model 

20 The proxy model is simple for the merchant to integrate into their Web site. It 

requires software modification on the part of the payment processors since it is 
implemented using their established APIs. 

14 
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The state diagram in Figure 1 depicts the order of network calls in the proxy 
model. Initially, the consumer begins by visiting the checkout page of the merchant's 
Web site. From there, the following interactions and transactions take place: 

1) The consumer selects the inventive payment option by clicking a link on 
5 the shopping cart page. This link is a link to the IMC Web server. It will 

pass as parameters the merchant id, order id and amount. The IMC Web 
server creates a session record to store the merchant id, order id and 
amount. The IMC Web server returns a page that contains an Active X 
control or signed Java applet. It will also contain a form in which the 
10 consumer will enter their PIN number 

2) Once loaded, the Active X control reads the card id from the physical 
medium in the consumer's drive. It will prompt the consumer to insert the 
card if there is no card available. The consumer will also enter their 
Personal Identification Number. When the consumer submits the PIN 

15 form, both the consumer's PIN and the card ID are posted to the IMC 

server. The IMC Web server verifies that the consumer has provided the 
correct PIN for the Card ID. It stores the Card ID in the session record. It 
then retums a page that contains an Active X control or signed Java applet 
that reads the next token in the series of tokens that is the one-time pad. 

20 The page also preferably uses a form to prompt the consumer to select one 

of the payment types available to them. 
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3) The Active X control reads the next token off the one time pad from the 
medium in the consumer's drive. The consumer will select a payment 
method. When the user submits the payment method form, both the 
selected payment method and the next token from the one time pad will be 

5 posted to the IMC Web server. 

The IMC Web server will verify that the token is indeed the next token in 
the one time pad. At this point, the service provider has all of the information 
necessary for transaction processing stored in the session record. Before control 
returns to the browser, the IMC server will process the transaction for the 
10 consumer. 

Using the Card ID, the IMC server queries the database for the 
information required to process the transaction for the consumers selected 
payment method. For example, in the case of a credit card payment method, this 
would be the card number, expiration date, and billing address. This information 
15 has been provided by the consumer at registration. 

4) The IMC server will request an authorization from at payment processor. 
The payment processor will return an approval code that will specify 
whether the transaction has been authorized, and if not the reason why. If 
the transaction is not approved the IMC Web server retums a page 

20 informing the consumer of the rejection with a form that will allow the 

consumer to select a different payment method. 



16 



SSO-10002/29 
02804sh 



5) When the transaction is approved, the IMC server will inform the 
merchant of the approval. It will do this by posting a message to a CGI 
script running on the merchant's Web server. The message will contain the 
order ID that has been stored in the session record along with the approval 
code returned from the authorization call to the payment processor. If the 
post to the merchant fails for some reason, the message will be queued for 
subsequent attempts at posting, the network administrators will be paged, 
and the IMC Web server will retum a page that will inform the consumer 
that their transaction has been approved, but the merchant has not yet been 
notified of the approval. 

6) After a successful post, the IMC Web server retums a page informing the 
consumer that their transaction was successful. This page contains a link 
to a script on the merchant's Web site that will generate a detailed order 
receipt. The link will pass the order ID as a parameter to the receipt script. 

To integrate the service, the merchant will create a link on their checkout page 
that will be labeled in accordance with the inventive payment option. The link will pass 
the order ID, merchant id, and amount to the IMC Web server. The merchant's checkout 
page will have to dynamically change this link for each order. Once the transaction has 
been approved, the IMC server will post the approval code with the order ID to the 
merchant's Web server. The merchant will have to create a CGI script that will receive 
the order ID and approval code from the service provider. 
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Pseudo Credit Card Model 

With the pseudo-credit model, the merchant has to do even less modification to 
their existing software base. After the IMC server performs the token-based 
authentication, it generates a pseudo-credit card number that is returned to the 
5 consumer's Web browser in a form. This form posts to the merchant's existing order 
processing script where it is treated like an ordinary credit card submission and 
forwarded to a payment processor. The payment processor then contacts IMC to 
exchange the pseudo-credit card number for the consumer's actual credit card number. 
If the credit card number itself is not large enough to uniquely identify 
10 transactions even when combined with a merchant ID, other fields that are commonly 
used in credit card transactions can be used to provide the necessary bandwidth. The 
billing address fields are candidates for the additional space. 

The state diagram in Figure 2 illustrates the pseudo-credit card model. The 
network traffic is identical to the proxy model until the consumer submits their payment 
15 method choice. 

The IMC Web server receives the next token off the one time pad and the 
payment type. It verifies that the token is indeed the next token in the one time pad. 
The payment method is stored in the session record. 

The IMC Web server generates a unique identifier for this transaction. The 
20 unique identifier will be associated with the session data that has been stored in the 
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session record. The unique identifier is retuned in hidden fields in a form to the 
consumers browser. 

When the consumer submits the form, it posts the pseudo-credit card 
information to the merchant's order processing script. The merchant's order processing 
5 script processes the form submission by forwarding the pseudo-credit card information 
to the payment processor. 

The payment processor identifies the pseudo-credit card information as 
originating from the service provider. It forwards the pseudo-credit card information to 
the IMC server. The IMC server retrieves the session record associated with the unique 
10 identifier encapsulated in the pseudo-credit card information. The IMC server returns to 
the payment processor the actual credit card number, expiration date, and billing address 
for the payment method that the consumer selected. The payment processor authorizes 
the transaction and returns an approval code to the merchant. The merchant stores the 
approval code and begins order fulfillment. It returns a page containing a detailed receipt 
15 to the consumer's Web browser. If the approval code indicates that the transaction has 
been denied, the merchant retums a Web page informing the consumer of the denial. 

Database Schema 

The following will detail the database schema for the IMC database by dividing 

the ERD into two components. One of the major tasks of the IMC database is to store 

20 cardholder information, including account information. The cardholder view of the ERD 

in Figure 3 depicts the entities and relationships that together form the cardholder model. 

19 
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This information will be updated by the cardholder through a Web interface when the 
visit the IMC Web site. It will also be edited by customer service representatives in 
response to a cardholder inquiry, or by data entry personnel. 

The cardholder view of the ERD contains a separate entity for addresses. Entities 
5 that would otherwise duplicate address fields in their own definition instead have a many 
to many, or many to one relationship with the address entity. The address entity is used 
by merchant and account entities, for example. 

The card entity represents a physical medium according to the invention, and 
stores the tokens and the index of the next valid token. From the card entity, one can 
10 derive the cardholder and a list of accounts that can be used to make purchases. 

Entities that will be modified over time by the cardholder and customer service 
representatives will have those modifications tracked by the database. It will be possible 
for customer representatives to determine when a cardholder's information was last 
modified, how it was modified and by whom. 
15 The address, cardholder and account entities all contain the field "edited by" 

which contains the representative id of the last representative to edit the record, or no 
value if the cardholder last edited the record. Both the "edited by" and the "modified" 
fields are updated each time the entity updated. 

All changes made to these tables will be recorded in history tables. This will 
20 allow customer representatives to view the changes made to a cardholder's account 
information over time. The representative will be able to roll back erroneous 
modifications to the cardholder's data. 
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For each entity whose change history is tracked there will be a history table that 
contains the same fields as the entity with an additional field in the key to denote the 
sequence of the edit, and an additional non-identifying field to indicate whether or not the 
entity has been deleted. 

5 The IMC database must also store the information required to authenticate a 

transaction. Each time a consumer attempts to authenticate a transaction an authorization 
session record is created. As information is sent firom the consumer's Web browser, that 
information is stored in the session record. 

In the pseudo-credit card model, the authorization session entity is uniquely 

10 identified by the pseudo-credit card number. When the payment processor receives the 
pseudo-credit card number, it will retrieve the actual credit-card information firom the 
IMC server. The IMC server will obtain this information by referring to the authorization 
session record. Once the transaction associated authorization session has been 
completed, the authorization session entity becomes a record of the transaction. 

15 Physically the transactions may be stored in a different table. 

Systems Architecture 

The invention preferably uses state-of-the-art, redundant, secure computing and 
networking systems, along with high-quality, stable, secure operating systems, redundant 
hardware and networking, and advanced Internet security technology. In all cases, 
20 redundancy will be used to enhance reliability. For instance, Oracle database replication 
will preferably be used to keep a hot backup of the production database server, multiple 

21 
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web servers with load-sharing and monitoring software (e.g., Resonate), RAID instead of 
individual disks, etc. Sun's Solaris is preferred as the primary operating system. Solaris is 
very stable, performs well, is well-understood, and can be made highly secure. For 
certain applications, OpenBSD or FreeBSD may be used, depending upon their state of 
5 development. 

The networking infrastructure will preferably use Cisco routers. For Intemet 
security, we will use the security features of the Cisco routers, as well as application-level 
firewalls (Network Associates Gauntlet or Checkpoint Firewall-1). Our database servers 
containing confidential consumer information will be protected behind multiple filtering 

10 routers and firewalls, and will be running on secure operating systems. This approach of 
using multiple, complementary methods for system security assures a high level of 
security. The Intemet connection will preferably have Cisco filtering rules, such that 
only necessary traffic is allowed through, packets are checked for appropriate source & 
destination, broadcast echo requests are disallowed, etc. 

15 Behind this Cisco will sit the "DMZ" (de-militarized zone), which will contain the 

web servers that need direct connections to the Intemet: the front-end servers which serve 
consumer content, and the merchant connectivity servers which contact merchants to note 
payment authorization (under one potential protocol design). Connecting the DMZ to the 
"Private side" will be a pair of systems, to provide redundant security - if one fails, we 

20 have the other. First, there will be an application-level firewall such as Gauntlet or 
Checkpoint, which can perform active checks on the data being passed through to the 
other side. Next will be another Cisco router with a more-restrictive filter list. 
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Availability is also a major concern. Consumers will want to be able to use their 
physical media at any time of the day or night. Multiple physical sites will therefore 
preferably be used, including multiple database servers, firewalls, and network hardware, 
and high-availability and load-balancing software on the front-end web site. 

5 Physical Media Production 

The physical medium preferably takes the form of a small, easily transportable 
card with variable dimensions for use with any standard device drive capable of reading 
Iji and writing data to and from computer-readable media. A preferred physical medium 

□ according to the invention is a recordable CD-ROM card having the size and form of a 

O 10 creditor business card, as shown in Figure 7. Such media can currently hold 20 Mbytes 
JL of data, though a larger form is now available which can hold around 50 Mbytes of data, 

jy The approximate dimensions of 2 inches by 4 inches by 1/16"^ inch or less facilitate 

a easy portability in a wallet. A fiiU-size disk may also be used. Multicolored images are 

best imposed onto a card via a large volume silk-screen process. A card can be visually 
15 individualized with a black ribbon printer during the recording process. Individualization 
could include a unique name, serial number, or bar code. The data recorded into a card 
is unique and is obtained from a repository under control of the inventive service 
provider. Currently, a single robotic machine consisting of four CDR-drives and one 
black printer can produces 100 cards per hour. 
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One skilled in the art will recognize that the physical and functional design 
characteristics of the medium may be implemented in a variety of ways, so long as the 
implementation conforms to the functional requirements described herein. In addition, 
the card may be encoded on both sides, as technology permits, and information other 
5 than the use tokens described below may be encoded. For example, advertising or 
other information may be contained on the card, thereby at least partially offsetting the 
cost of manufacture and/or distribution. 

Figures 8 shows an alternative medium in the form of an expandable magnetic 
medium 302. In this configuration, the expandable magnetic medium 302 in its 

10 collapsed state measures approximately 2 inches by 4 inches by 1/16^'' inch, thereby 
permitting the consumer to easily transport the expandable medium 302 as one would a 
credit card. In its expanded state, however, the magnetic medium 302 approximates 
the dimensions of a standard 3.5-inch floppy diskette. 

The expandable magnetic medium 302 is constructed from a durable plastic and 

15 metal combination housing an inner magnetic disk 322 shown in phantom lines for data 
storage. In the collapsed state, two protective outer sleeves 224 meet along an axis of the 
expandable magnetic disk, protecting the inner magnetic disk 322, and a third metal 
protective sleeve 326 located along a front edge of the magnetic expandable package to 
protect the inner magnetic disk 322. 

20 Due to the reduced overall size of the expandable magnetic medium 302 in its 

collapsed state, the diameter of inner magnetic disk 322 is substantially less than the 
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diameter of a magnetic disk of a standard 3.5 floppy diskette. For this reason, the data 
storage capacity of the expandable magnetic medium 322 is reduced, and the distance the 
irmer magnetic disk 322 extends into the drive is reduced as well. To accommodate the 
aforementioned reductions, a file allocation table (FAT) located at the interior portion of 
5 the inner magnetic disk 322 instructs a read/write head of the drive to search areas on the 
inner magnetic disk 322 where data is stored. The read/write head reads the FAT 
instruction on initialization of the personal computer and the associated disk drive, and 

□ eliminates drive errors due to an absence of magnetic medium under the entire length of 

r=~ 
£=? 

H head track during read/write operations to the expandable magnetic medium 302. 

^10 To use the expandable medium, the consumer slides each outer sleeve along the 

=5 length of the second protective metal sleeve 224 and away from the center of the 

expandable magnetic medium 302. The two protective outer sleeves 224 bring the 
II overall width of the expandable magnetic disk 302 to 3.5 inches. The outer sleeves 224 

□ snaps into place using a simple spring and groove system with track and groove similar to 
15 the protective portions found on a traditional 3.5-inch diskettes. Alternatively, the two 

outer sleeves 224 slide across a J-shaped groove track to lock into place. To collapse the 

expandable magnetic medium 302 to its smaller size, simply pull each outer sleeve 23 

outward and away from the center of the expandable magnetic medium a fraction of an 

inch, and it snaps back to its reduced size using the J-grooves with a spring mechanism. 

20 One skilled in the art will recognize that multiple means for expansion and 

various design techniques are available in for this embodiment of the present invention. 

For example, a winged model 420 of the expandable medium shown in Figure 9 replaces 
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the outer sleeves 224 found in the expandable magnetic medium 302 a hinged wing on 
each side. The hinged wings affix with a standard rivet-style pin protruding through the 
expandable magnetic disk, and expand and collapse to provide dimensions appropriate 
for transportation and use of the winged model of Figure 9. 
5 In addition to the uses described above, the one-time data tokens may be 

cryptographically derived identifiers representing a monetary value, each of which may 
be used to authorize a single transaction. For example, a dollar may be represented on 
the medium as a coded multidigit alphanumeric number (hereinafter, an AN string). 
With each AN string utilizing 16 bytes of storage space, the 120,000 byte usable surface 
10 will store approximately 7500 AN strings, or the equivalent of $7500.00 per medium. A 
slightly enlarged version of the medium holds approximately 29,437 AN strings, or $29, 
437. 

The remaining authentication data on the optic medium may be used to prevent 

the interception and unauthorized use of data tokens during reapplication of monetary 

15 value. If a consumer depletes the one-time data tokens on the optic medium, the 

consumer may apply more monetary value to the optic medium by consummating an 

online withdrawal from a bank or other authorized institution. 

The transfer of the one-time data tokens in this case preferably employs a two-tier 

scheme to secure the one-time data tokens 528 while enroute to the medium. First, upon 

20 issuance of each medium, a two-digit code is encrypted and hidden thereon, and the 

authentication server stores the two-digit number along with a reference to the associated 

medium. Upon request for revaluation of the medium, the authentication server 
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downloads a sequence of 12-digit, unique AN strings. After download, the hidden two- 
digit code is added to each AN string to make a 14-digit AN string. Second, the 
authentication server adds a two-digit code and one hundred random AN strings to the 
download data. The one hundred random AN strings mask the two-digit, preventing 
deciphering of the same. 

Once the dovraload completes, the two-digit code appends to each 14-digit AN 
string to complete the final 16-digit sequence necessary for a one-time data token. The 
authentication server records the complete 16-digit AN string by compiling all 
information pertaining to a 16-digit AN string from the authentication server information. 
Any attempt to intercept an AN string enroute to a consumer's personal computers results 
in, at best, the capture of a 12-digit, meaningless number. The inability to easily 
ascertain the two-digit code transferred with the AN strings coupled with an inability to 
ascertain the secret two-digit code hidden on each medium presents a robust, secure 
means to revaluate the same. 

The encoded data may also include application data for marketing, promotional, 

and other purposes. It is anticipated that the device drive connected to the personal 

computer reads the medium and transfers the application data to personal computer of the 

consumer for display on the video display unit in the form of images, video and other 

multimedia means designed to capture the attention of the consumer. The application 

data typically includes the logo of the issuing institution of the optic medium, media-rich 

advertising in the form of video clips, sound bytes, and other means to target the 

consumer. For example, the consumer's personal computer interacts with the merchant's 
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server to process a payment transaction; the personal computer may concurrently display 
an advertisement utilizing several media on the video display monitor. 

It is anticipated that the various payment transaction models implemented for use 
with the present invention offer multiple methods to obtain and activate the medium. 
5 Some media are distributed in an immediately usable form, while others require 
consumer activation before use. In some case, a provision of a PIN number activates the 
medium, wherein the PIN number is known only to a consumer and an authentication 
server, and not encoded on the medium. In other cases, the activation requires the 
provision of a credit card or other valid payment instrument to associate with the medium 
10 itself For example, the issuing bank preapproves consumers and the consumers requests 
the medium, the medium company provides media via a mass distribution scheme, or 
merchants offer retail stored-value cards. Each of these examples is discussed in detail 
below. 

Figure 10 depicts the events in one method for issuing, providing, and activating 

15 the medium. Initially, a source 630 produces the media 631 in volume, and ships a 

medium to a consumer 632 upon request. The consumer utilizes a personal computer and 

the medium 631 to logon to a bank website 634 and provide information about the 

medium 631. The bank website 634 issues a PIN number 633 for the consumer for 

validation purposes. The bank website also contacts the authentication server 635 and its 

20 associated network of servers to provide the consumer account data relevant to the 

medium and the consumer 632. The authentication server 635 and the associated 

network of servers add the PIN number to the information pertaining to that particular 
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medium 631 already stored in its database. The authentication server 635 then contacts 
the issuing bank 636 to exchange consumer account data, at which time the activated card 
may be used by a the consumer. 

Figure 1 1 depicts the events surrounding a mass distribution method for providing 
5 media to consumers. Card production at a source 741 produces inactivated volumes of 
media 742 that are distributed to a population 743 of people via a predetermined plan and 
means. The distribution plan includes a provision for a separate distribution of unique 
PIN numbers, each corresponding to a medium 742 and each distributed via a separate 
channel from the medium 742 to prevent a breach of security. 

10 Once the consumer receives both the medium 742 and the PIN number, the 

consumer uses a personal computer to access a website associated with the bank 744 of 
the consumer. The PIN number and payment data on the card are forwarded via secure 
means to the website, and on to the authentication server 745 and its associated network 
of servers for activation. The authentication server 745 routes the activation data through 

15 the website of the bank 744, at which time the consumer can use the medium for online 
payment transactions. 

Figure 12 depicts a distribution and activation process whereby the source 851 
produces and encodes media 852 complete with authentication data and a series of one- 
time data tokens; i.e., active and ready for use by a consumer. The production and 

20 encoding process is implemented according to a predetermined plan in conjunction with 
an issuing bank 853, whereupon the individual data associated with each medium is 
transmitted to an authentication server 853a and its associated network of servers. Once 
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the media are produced, they are distributed via a secure method; e.g., armored truck 854 
to a retail estabhshment 855. Upon purchase by a consumer 856 from the retail 
establishment 855, the consumer can immediately use the medium 852 in conjunction 
with a personal computer system 857 for online payment transactions with various 
websites 858 associated with various merchants. 

Having illustrated and described the principles of the system, method, and 
apparatus of the present invention in various embodiments, it should be apparent to those 
skilled in the art that the embodiment can be modified in arrangement and detail without 
departing from such principles. For example, the physical manifestation of the medium 
may be changed if preferred. Therefore, the illustrated embodiments should be 
considered only as example of the invention and not as a limitation on its scope, which is 
defined by the following claims. We therefore claim as our invention all modifications 
and equivalents to the embodiment coming within the scope and spirit of these claims. 
We claim: 
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